Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

umu-launcher[-unwrapped]: init at 1.1.4 #369259

Merged
merged 1 commit into from
Jan 19, 2025
Merged

Conversation

diniamo
Copy link
Contributor

@diniamo diniamo commented Dec 29, 2024

Closes #297662

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

@diniamo
Copy link
Contributor Author

diniamo commented Dec 29, 2024

Oh yeah, the build fails because of #366359, I've been working on this with doCheck = false in hatch's package definition.

@github-actions github-actions bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 1-10 labels Dec 29, 2024
@diniamo diniamo changed the title umu-launcher: init at 1.1.4 umu-launcher[-unwrapped]: init at 1.1.4 Dec 30, 2024
@diniamo diniamo force-pushed the umu-launcher branch 2 times, most recently from 73f963a to 9257d01 Compare December 30, 2024 01:41
@ofborg ofborg bot added 8.has: package (new) This PR adds a new package 11.by: package-maintainer This PR was created by the maintainer of the package it changes labels Dec 30, 2024
@beh-10257
Copy link

do not look at it if you care about your eyesight

instead of saying this type of stuff why don't you tell me what are your complaints and actually make an improvement

@diniamo
Copy link
Contributor Author

diniamo commented Jan 7, 2025

Sorry. The improvement is this package, since I saw more value in upstreaming a proper package to nixpkgs compared to fixing the problems in the flake.

@diniamo
Copy link
Contributor Author

diniamo commented Jan 7, 2025

On another note, @MattSturgeon please mark the threads as resolved if they are.

Also, should I add you and @beh-10257 as maintainers to the package (assuming you're already in the maintainers list)?

@beh-10257
Copy link

the flake is always gonna be more up to date so there is value in that
yes add me to the maintainers list
can you list the improvements so I can make the flake better like I'm trying to make things better here so cooporate

@MattSturgeon
Copy link
Contributor

On another note, @MattSturgeon please mark the threads as resolved if they are.

I don't have permission to do that. I think as PR author you can? Otherwise someone with write-access must do it.

@diniamo
Copy link
Contributor Author

diniamo commented Jan 7, 2025

Huh? You should be able to resolve your own reviews. Well in that case, do you want to add anything else or can I resolve them?

@diniamo
Copy link
Contributor Author

diniamo commented Jan 7, 2025

...can you list the improvements so I can make the flake better...

@beh-10257 most of them you can get by replacing the package definitions entirely with the ones from this PR, while adapting them for the flake (make sure to tell me about anything that's missing from the packages in this PR along with a good reasoning as well, so I can add them too; eg. optional dependencies, since I couldn't find anything about those, but I did see some in the Nix package). Once you do that, I'll PR the rest of my suggestions, since that's easier than explaining.

@MattSturgeon
Copy link
Contributor

MattSturgeon commented Jan 7, 2025

Huh? You should be able to resolve your own reviews.

From Resolving conversations:

You can resolve a conversation in a pull request if you opened the pull request or if you have write access to the repository where the pull request was opened.

Well in that case, do you want to add anything else or can I resolve them?

Most of my threads were more discussion than feedback. If you feel that they are resolved, then feel free to mark as such.


the flake is always gonna be more up to date so there is value in that
can you list the improvements so I can make the flake better like I'm trying to make things better here so cooporate

I agree it'd be nice if the flake and nixpkgs were kept in sync. This will likely need breaking changes though.

One way that could be done would be to have the flake base itself on the nixpkgs impl, simply overriding src to point to the upstream repo. E.g:

# flake outputs
{
  overlays.default = final: prev: {
    umu-launcher-unwrapped = prev.umu-launcher-unwrapped.overrideAttrs (old: {
      # TODO: would be nice to filter out irrelevant dirs,
      # to avoid them invalidating build caches
      # e.g. using filesets
      src = ../../.;

      # TODO: version should also be something sensible
      version = "?";
    });
  };
}

One way to avoid that being an invisibly breaking change, would be to add a new flake.nix to the root of the upstream repo.

By keeping the old flake at its existing location (with a warning), users would have time to migrate to the new flake at the new location.

That way a) end-users don't need ?dir=packaging/nix and b) the old flake can be left as-is for a period of migration.

@diniamo
Copy link
Contributor Author

diniamo commented Jan 7, 2025

Not needing ?dir=packaging/nix would be the breaking change, as it's been there previously. Also yeah, an override-based approach would be nice.

@MattSturgeon

This comment was marked as resolved.

@LovingMelody
Copy link
Contributor

Please add me to the maintainers list as well (fuzen)

@diniamo
Copy link
Contributor Author

diniamo commented Jan 11, 2025

Added the 2 of you, but I couldn't find @beh-10257

@@ -0,0 +1,15 @@
{ buildFHSEnv, umu-launcher-unwrapped }:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be worth copying heroic

extraPkgs ? pkgs: [ ],
extraLibraries ? pkgs: [ ],

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make it easier for end-users to add extra packages to the FHS environment by overriding.

This could be done in a follow-up PR if preferred

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I what the code does, but in what scenario would that be useful

I assume heroic launcher also supports native games, in which case it would make sense, but as far as I know, umu is for windows games only

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needed for passing graphics and fixing a cursor issue. Graphics is needed for dxvk-nvapi to work

extraLibraries = pkgs: let
prevLibs = if prev ? extraLibraries then prev.extraLibraries pkgs else [ ];
additionalLibs = with config.hardware.graphics;
if pkgs.stdenv.hostPlatform.is64bit
then [ package ] ++ extraPackages
else [ package32 ] ++ extraPackages32;
in prevLibs ++ additionalLibs;

Copy link
Contributor Author

@diniamo diniamo Jan 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know, I feel like these make more sense to be done with overrides.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m pretty new to nixpkgs and all but I’m going to second @LovingMelody on this one, I think adding the options to enable easier overrides would be a good thing, particularly since I suspect that will be something done often as shown with steam there. As mentioned though having it be in a separate PR is fine I think.

@diniamo
Copy link
Contributor Author

diniamo commented Jan 17, 2025

Fixed formatting

Copy link
Contributor

@MattSturgeon MattSturgeon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah, the build fails because of #366359, I've been working on this with doCheck = false in hatch's package definition.

The fix (#371743) is currently in staging-next. Not sure how long until that'll be merged into master.

pkgs/by-name/um/umu-launcher-unwrapped/package.nix Outdated Show resolved Hide resolved
pkgs/by-name/um/umu-launcher-unwrapped/package.nix Outdated Show resolved Hide resolved
pkgs/by-name/um/umu-launcher-unwrapped/package.nix Outdated Show resolved Hide resolved
pkgs/by-name/um/umu-launcher/package.nix Outdated Show resolved Hide resolved
pkgs/by-name/um/umu-launcher/package.nix Outdated Show resolved Hide resolved
@MattSturgeon
Copy link
Contributor

MattSturgeon commented Jan 17, 2025

Also, should I add you and @beh-10257 as maintainers to the package (assuming you're already in the maintainers list)?

yes add me to the maintainers list

Added the 2 of you, but I couldn't find @beh-10257

It seems they aren't in the list. It'd be great to have them, but they'll have to do that themselves in a follow up PR.

@beh-10257 see the relevant documentation:

@diniamo diniamo force-pushed the umu-launcher branch 3 times, most recently from 64fef4c to be2f0c5 Compare January 18, 2025 16:36
@diniamo
Copy link
Contributor Author

diniamo commented Jan 18, 2025

Sigh... that should be fine for the remaining reviews.

I'm not willing to add the extra* stuff however, unless another another committer wants them, as I really don't think they make sense, when they are only required for workarounds (that can also just as easily be done with overrideAttrs).

@diniamo
Copy link
Contributor Author

diniamo commented Jan 19, 2025

@MattSturgeon does that look ok?

Comment on lines 26 to 27
# Ideally, a change should be upstreamed, that adds both arguments
# if their respective variables are set.
Copy link
Contributor

@MattSturgeon MattSturgeon Jan 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# Ideally, a change should be upstreamed, that adds both arguments
# if their respective variables are set.
# See https://github.com/Open-Wine-Components/umu-launcher/pull/343

I've opened an upstream PR, so let's link to it 🙃

Copy link
Contributor

@MattSturgeon MattSturgeon Jan 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's merged now, so we can safely use fetchpatch2:

diff --git a/pkgs/by-name/um/umu-launcher-unwrapped/makefile-installer-prefix.patch b/pkgs/by-name/um/umu-launcher-unwrapped/makefile-installer-prefix.patch
deleted file mode 100644
index 890d6537e33c..000000000000
--- a/pkgs/by-name/um/umu-launcher-unwrapped/makefile-installer-prefix.patch
+++ /dev/null
@@ -1,13 +0,0 @@
-diff --git a/Makefile.in b/Makefile.in
-index b82053d..3e4379e 100644
---- a/Makefile.in
-+++ b/Makefile.in
-@@ -90,7 +90,7 @@ umu-dist: $(OBJDIR)/.build-umu-dist
- umu-dist-install: umu-dist
- 	$(info :: Installing umu )
- 	install -d $(DESTDIR)$(PYTHONDIR)/$(INSTALLDIR)
--	$(PYTHON_INTERPRETER)  -m installer --destdir=$(DESTDIR) $(OBJDIR)/*.whl
-+	$(PYTHON_INTERPRETER) -m installer --prefix=$(PREFIX) $(OBJDIR)/*.whl
- 
- ifeq ($(FLATPAK), xtrue)
- umu-install: version-install umu-dist-install
diff --git a/pkgs/by-name/um/umu-launcher-unwrapped/package.nix b/pkgs/by-name/um/umu-launcher-unwrapped/package.nix
index 357ef7a5d806..1f97d0c31580 100644
--- a/pkgs/by-name/um/umu-launcher-unwrapped/package.nix
+++ b/pkgs/by-name/um/umu-launcher-unwrapped/package.nix
@@ -1,6 +1,7 @@
 {
   python3Packages,
   fetchFromGitHub,
+  fetchpatch2,
   lib,
   bash,
   hatch,
@@ -22,10 +23,12 @@ python3Packages.buildPythonPackage rec {
     # This should fail, and be removed for releases after 1.1.4,
     # see https://github.com/Open-Wine-Components/umu-launcher/pull/289
     (replaceVars ./no-umu-version-json.patch { inherit version; })
-    # Patch the python installer call to use --prefix instead of --destdir
-    # Ideally, a change should be upstreamed, that adds both arguments
-    # if their respective variables are set.
-    ./makefile-installer-prefix.patch
+    # Patch the python installer call to support PREFIX
+    # see https://github.com/Open-Wine-Components/umu-launcher/pull/343
+    (fetchpatch2 {
+      url = "https://github.com/Open-Wine-Components/umu-launcher/pull/343.diff";
+      hash = "sha256-+h0ao2WUVUUR/AHEtGj5IAIUVivfAc+asnr0632hN74=";
+    })
   ];
 
   nativeBuildInputs = [

@MattSturgeon
Copy link
Contributor

Oh yeah, the build fails because of #366359, I've been working on this with doCheck = false in hatch's package definition.

The fix (#371743) is currently in staging-next. Not sure how long until that'll be merged into master.

#371743 has finally made it to master 🎉

Copy link
Contributor

@MattSturgeon MattSturgeon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Installed & tested locally, seems to be working.

Thanks for your efforts on this!

@MattSturgeon

This comment was marked as outdated.

@MattSturgeon MattSturgeon added 12.approvals: 1 This PR was reviewed and approved by one reputable person 12.approved-by: package-maintainer This PR was reviewed and approved by a maintainer listed in the package labels Jan 19, 2025
MattSturgeon added a commit to MattSturgeon/nix-config that referenced this pull request Jan 19, 2025
Test out the nixpkgs PR instead of using the upstream flake

NixOS/nixpkgs#369259
@khaneliman
Copy link
Contributor

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 369259


x86_64-linux

✅ 2 packages built:
  • umu-launcher
  • umu-launcher-unwrapped

aarch64-linux

✅ 2 packages built:
  • umu-launcher
  • umu-launcher-unwrapped

@khaneliman khaneliman merged commit 0d199cb into NixOS:master Jan 19, 2025
27 of 29 checks passed
@diniamo
Copy link
Contributor Author

diniamo commented Jan 19, 2025

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
8.has: package (new) This PR adds a new package 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 1-10 11.by: package-maintainer This PR was created by the maintainer of the package it changes 12.approvals: 1 This PR was reviewed and approved by one reputable person 12.approved-by: package-maintainer This PR was reviewed and approved by a maintainer listed in the package
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Package request: umu-launcher
6 participants